NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/203

Text File | 1996-08-06 | 9.1 KB | 210 lines

Path: ix.netcom.com!netnews
From: [e-mail] (Mike Rubenstein)
Newsgroups: comp.lang.c++,comp.lang.c,comp.std.c
Subject: Re: Hungarian notation
Date: Sat, 27 Jan 1996 14:21:46 GMT
Organization: Netcom
Message-ID: <[e-mail]>
References: <[e-mail]> <4d2ok0$[e-mail]> <[e-mail]> <[e-mail]> <4e1nd8$[e-mail]> <[e-mail]> <dewar.822407919@schonberg> <[e-mail]> <4e6oj9$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <4eco1g$[e-mail]>
NNTP-Posting-Host: ix-dc6-22.ix.netcom.com
X-NETCOM-Date: Sat Jan 27  6:21:52 AM PST 1996
X-Newsreader: Forte Agent .99c/16.141

[e-mail] (Gene Wirchenko) wrote:

> [e-mail] (Mike Rubenstein) wrote:
>
> >[e-mail] (Jon S Anthony) wrote:
>
> >NOTE:  I've removed all groups from this posting except comp.lang.c
> >and comp.lang.c++ and have added cmp.std.c
>
> >Since I've added a new group, let me summarize a bit.  The discussion
> >revolves around the result of converting a signed integral type to a
> >smaller type when the value in the original cannot be represented in
> >the new type.
>
> >I claim that ISO 6.2.1.2 requires that an implementation actually do
> >such a conversion.  The implementor may choose the mapping.  Beside
> >the usual throwing away of high order bits, possibilities include
> >always using the value 0, or the largest possible value for the new
> >type, or, even, a random value.
>
>      Or even a random value for your system disk <G>.
>
>      Implementation defined means implementation defined, not what you
> want it to mean.  I agree that your interpretation sets out reasonable
> actions that might be performed.  Please quote chapter and verse on
> where the Standard states that implementation defined actions must be
> "reasonable" (whatever the hell that is <G>).
>
> >However, I claim that a conversion is required -- the implementation
> >must come up with a value that can be represented in the new type and
> >use that.  It may not do other things like, as one person claimed,
> >deleting the system disk even if such action is documented.
>
>      Is your claim supported in the Standard?  If it isn't, you're
> wasting your time.  What if the conversion results in overflow?
>
> >> In article <[e-mail]> [e-mail] (Mike Rubenstein) writes:
> >>
> >> > [e-mail] (Jon S Anthony) wrote:
> >> >
> >> > > In article <[e-mail]> [e-mail] (Mike Rubenstein) writes:
> >> > >
> >> > > > I think you're reading something into my post that isn't there.
> >> > > >
> >> > > > What am I reading into the standard that's not there?  Nothing in my
> >> > > > post suggests that defining the result as always 0 is illegal.  In
> >> > > > fact, it is clearly legal.
> >> > > >
> >> > > > But the standard does impose some restrictions on the definition.  The
> >> > > > definition must specify that the subject type is converted to the
> >> > > > object type.  It must not produce side-effects.
>
>      Why are no side effects permitted?  Chapter and verse, please.

For the same reason an implementation is not permitted to introduce
side effects into the expression 1 + 2.  The standard defines the
result as a conversion and that is what must be done -- nothing else
may be done (that is detectable by a conforming program).

According to ISO 1,

    This International Standard specifies the form and establishes

    the interpretation of programs written in the C programming
    language.  It specifies

    ...

    - the semantic rules for interpretting C programs;

Where the standard specifies a conversion, I have the right to expect
a conversion and not any other action.

>
> >> > > >
> >> > > > Please reread my post; I was responding to the statement that the
> >> > > > definition could be to delete the system disk.  That is out of bounds
> >> > > > for the definition and I said so.  I did not say that defining the
> >> > > > result to be 0 is out of bounds.
> >> > >
> >> > > Face it.  You just plain got it wrong.  Deleting the system disk is
> >> > > perfectly within bounds.  Stupid, for sure, as no one in their right
> >> > > mind would use such a compiler, but perfectly legal.
> >> >
> >> > Please cite anything in the standard that supports your position.  I
> >> > can find nothing in the standard that gives an implementation that
> >> > license.
>
>      If "implementation defined" does not qualify as "that licence",
> what in your eyes would?

Undefined behavior.  Implementation-defined behavior in a situation in
which the standard does not impose requirments.

Implementation-defined behavior occurs for correct constructs with
correct data (ISO 3.11).  It does not free the compiler from the
obligation of complying with the requirements of the standard.

>
> >> >
> >> > Insults do not prove a point -- quotes from the standard do.  I've
> >> > shown the passages that support my position.
> >>
> >> I don't see any insult here at all.  Sorry if you took it that way.
> >>
> >> Here's the relevant passage yet again:
> >>
> >>      When a value with integral type is demoted to a signed integer
> >>      with smaller size or an unsigned integer is converted to its
> >>      corresponding signed integer, if the value cannot be
> >>      represented the result is implementation defined.
> >>
> >> Now, the problem is (as James Kanze has pointed out) that the term
> >> "result" which you believe to know the "correct" definition of, is not
> >> defined.  Because of this it _could_ be taken as meaning "result of
> >> the computation".  You take it as a given that it means "result of the
> >> expression", i.e., its value.  But that is not clear, and so an
> >> interpretation given the former reading would indeed allow for
> >> virtually any sort of behavior as long as that behavior was
> >> documented.  As James Kanze pointed out, a very _reasonable_
> >> interpretation given this reading of "result" would be to to signal
> >> (raise) an exception.
>
>      Agreed and this is what is keeping this argument going, eh?
>
> >I've not seen Jame's post, but I look forward to seeing it.
>
> >But, I don't see how the standard permits throwing an exception.  ISO
> >6.2 says
>
> >    Several operators convert operand values from one type to
> >    another automatically.  This subclause specifies the result
> >    required from such an implicit conversion, as well as those
> >    that result from a cast operation (an explicit conversion).
>
>      What if the conversion results in overflow?
>
> >It seems obvious to me that if one uses correctly a construction that
> >the standard says converts a value from one type to another, then the
> >implementation must convert the value from one type to another -- it
> >may not do other things.  By definition (ISO 3.10)
> >implementation-defined behavior only applies to a correct program
> >construct and correct data.
>
>      If it is impossible to convert due to sizing, then the "must" is
> rather silly, isn't it?
>
>      Would not the normal situation (especially since the point hasn't
> been raised previously) imply that the conversion we want done applies
> to a correct program construct and correct data?  Why would you assume
> anything else?  You are permitted to answer that you may do as you
> please because your assumptions are implementation defined <G>.
>
> >I'm glad you intended no insult.  I'm afraid I just don't react well
> >to ex cathedra statements that I am wrong, particularly when I have
> >taken  care to give clear citations that I believe support my
> >position.
>
>      Yes, but you keep saying "claim" and write as if you are the
> Right Hand of God.  So what about your claims!  If they can't be
> supported by the Standard, forget it.  Schildt CLAIMS that void main()
> is ok.

The fact that something is implementation defined does not free the
compiler from the obligation of complying with the standard.

Let's take a simple example.  Consider a machine with 8 bit characters
and the program

    #include <stdio.h>
    int main(void)
    {
       char c = (char) 256;
      printf("%d\n", c);
      return 0;
    }

From ISO 6.3.4,

    Preceding an expression by a parenthesized type name converts
    the value of the expression to the named type.

Here I have a correct construct (it meets the syntax and constraint
requirements of the standard) used with valid data.  No matter what, I
have the right to expect the semantics defined by the standard --
converting 256 to char -- will be implmented by the compiler.

The standard does not require the conversion to be reasonable
(whatever that means), but it does require a conversion.  Since this
is a conforming program, I have the right to expect that the
implementation will comply with the semantics required by the
standard.  The standard says that this program converts 256 to a char,
prints the char as a decimal number, and terminates execution with a
successful indication to the host.


Michael M Rubenstein